Embedding data in media metadata tracks during playback

ABSTRACT

Data is embedded onto new or existing media metadata tracks during playback of a media stream. A content server provides a media stream to a mobile device. Data associated with the playback of the media stream on the mobile device is obtained by the content server and saved to the media stream itself. Data may include playback statistics, viewing characteristics, channel changes, comment logs, etc. The information can be stored in a time-correlated manner to allow extraction and analysis of data.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present invention claims priority to co-pending provisional U.S.patent application No. 61/049,739, filed May 1, 2008, which isincorporated herein by reference in its entirety.

TECHNICAL FIELD

The present disclosure relates to embedding data in media metadatatracks during playback.

DESCRIPTION OF RELATED ART

A variety of conventional mechanisms obtain data and statisticsassociated with the playback of media streams. In many instances, theinformation is logged to allow later retrieval and analysis ofstatistics. The statistics may include viewing characteristics, networkperformance information, user settings, etc.

However, conventional mechanisms for maintaining information associatedwith the playback of media streams are limited. Consequently, it isdesirable to provide improved techniques and mechanisms for maintaininginformation associated with the playback of media streams.

BRIEF DESCRIPTION OF THE DRAWINGS

The disclosure may best be understood by reference to the followingdescription taken in conjunction with the accompanying drawings, whichillustrate particular embodiments.

FIG. 1 illustrates an exemplary system for use with embodiments of thepresent invention.

FIG. 2 illustrates one example of a Real-Time Transport Protocol (RTP)packet.

FIG. 3 illustrates one example of an RTP stream.

FIG. 4 illustrates one example of modification of an RTP streamincluding removal and insertion of packets.

FIG. 5 illustrates one example of embedding data in a media stream.

FIG. 6 illustrates an example of modifying a media stream based on dataembedded in a track.

FIG. 7 illustrates one example of a content server.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Reference will now be made in detail to some specific examples of theinvention including the best modes contemplated by the inventors forcarrying out the invention. Examples of these specific embodiments areillustrated in the accompanying drawings. While the invention isdescribed in conjunction with these specific embodiments, it will beunderstood that it is not intended to limit the invention to thedescribed embodiments. On the contrary, it is intended to coveralternatives, modifications, and equivalents as may be included withinthe spirit and scope of the invention as defined by the appended claims.

For example, the techniques of the present invention will be describedin the context of particular networks and devices. However, it should benoted that the techniques of the present invention apply to a variety ofnetworks and devices. In the following description, numerous specificdetails are set forth in order to provide a thorough understanding ofthe present invention. Particular example embodiments of the presentinvention may be implemented without some or all of these specificdetails. In other instances, well known process operations have not beendescribed in detail in order not to unnecessarily obscure the presentinvention.

Various techniques and mechanisms of the present invention willsometimes be described in singular form for clarity. However, it shouldbe noted that some embodiments include multiple iterations of atechnique or multiple instantiations of a mechanism unless notedotherwise. For example, a system uses a processor in a variety ofcontexts. However, it will be appreciated that a system can use multipleprocessors can while remaining within the scope of the present inventionunless otherwise noted. Furthermore, the techniques and mechanisms ofthe present invention will sometimes describe a connection between twoentities. It should be noted that a connection between two entities doesnot necessarily mean a direct, unimpeded connection, as a variety ofother entities may reside between the two entities. For example, aprocessor may be connected to memory, but it will be appreciated that avariety of bridges and controllers may reside between the processor andmemory. Consequently, a connection does not necessarily mean a direct,unimpeded connection unless otherwise noted.

Overview

Data is embedded onto new or existing media metadata tracks duringplayback of a media stream. A content server provides a media stream toa mobile device. Data associated with the playback of the media streamon the mobile device is obtained by the content server and saved to themedia stream itself. Data may include playback statistics, viewingcharacteristics, channel changes, comment logs, etc. The information canbe stored in a time-correlated manner to allow extraction and analysisof data.

Example Embodiments

In many systems, a content server provides a media stream to a mobiledevice. Numerous mobile devices playing the media stream generates alarge amount of data that can be transmitted back to the content server.In many instances, the content server collects user characteristics suchas channel changes, offers selected, volume light/dark controls, etc.,as well as network characteristics such as packet loss, throughput,retransmission, etc. As media streams are played by multiple users indifferent environments, the amount of data becomes substantial andpotentially unwieldy for analysis, particularly real-time playbackanalysis.

Streaming servers typically use logging to maintain data associated withmedia stream playback on devices such as mobile phones. Some networkdevices also log network performance metrics to track packet loss,throughput, retransmission rates, etc. However, no existing systemsallow efficient storage and management of data associated with mediastream playback.

The media streams that are delivered usually include at least an audiotrack and a video track, but the media streams may include additionaltracks. For example, media streams may also include captions, subtitles,and real-time metadata describing activity relating directly to thecontent presented on the other tracks.

According to various embodiments, a content server or other networkdevice records data to a new or existing track in a media stream inreal-time or near real-time as the media stream is being played by oneor more users. According to various embodiments, the data includeschannel changes, configuration selections, volume and screen brightnesschanges, option selections, chat logs, packet drops, throughput,retransmission rate, etc. Location, temperature, battery condition,network performance, local-time, and/or anything else happening on thedevice itself may be reported to a content server or other networkdevice and embedded onto a media stream in a track. The data may berecorded in a time-correlated manner on the media stream. For example,indications that many users adjusted the volume when a particularprogram ends may be recorded in the track corresponding to the point inthe media stream where the program ends.

According to various embodiments, a particularly high number of channelchanges may be recorded at the point where a commercial begins. In otherembodiments, a large number of packet drops may be recorded at thebeginning of a program sequence. In particular embodiments, networktransmission rates and commercial selection can be modified duringplayback to account for user feedback. The modifications can be madeduring particular points of media stream play back based on the dataembedded in the media track.

According to various embodiments, as media is played, available metadatais analyzed to allow a content server to dynamically modify the mediastream provided to a mobile device. Commercials identified by a datatrack as unappealing by particular demographic groups are replaced withalternate commercials.

In particular embodiments, more appropriate advertising can be providedbased on real-time feedback. Programs and commercials can be betterproduced/validated/verified. According to various embodiments,parameters collected from a media playback experience can be tightlybound to the media stream itself. Instead of using separate systems todeliver data and generate logs and summaries, collected data can becorrelated directly to media being played. According to variousembodiments, data derived from a variety of sources can be embedded innew or existing tracks within the media stream itself. In particularembodiments, the recording and retrieval of the data happens inreal-time or near real-time on every playback of a particular mediastream so that data can be used to adjust current playback parameters ofthe media as it is played a subsequent time.

In a particular example, if a particular network condition was observedin the last playback of a media segment that indicated packet loss,packetization of the media segment can be adjusted to prevent futurepacket loss. In yet another example, contents of a chat server arecorrelated with events in a media stream. Ratings buttons or otherquestion and answer responses are elicited. The chat session andquestionnaire statistics can be stored with the media stream and usedlater for search, replay, archival or other ratings and analysispurposes. By placing data associated with playback in the media streamitself, cumbersome correlation of events across different streams can bereduced. The embedded data can be continuously modified and/or expandedas needed. In some examples, playback options such as charts and graphscan be dynamically generated during playback.

FIG. 1 is a diagrammatic representation illustrating one example of asystem that can use the techniques and mechanisms of the presentinvention. According to various embodiments, content servers 119, 121,123, and 125 are configured to provide media content to a mobile device101 using protocols such as RTP and RTCP. Although a mobile device 101is shown, it should be recognized that other devices such as set topboxes and computer systems can also be used. In particular examples, thecontent servers 119, 121, 123, and 125 can themselves establish sessionswith mobile devices and stream video and audio content to mobiledevices.

According to various embodiments, the content servers 119, 121, 123, and125 have access to a campaign server 143. The campaign server 143provides profile information for various mobile devices 101. In someexamples, the campaign server 143 is itself a content server or acontroller. The campaign server 143 can receive information fromexternal sources about devices such as mobile device 101. Theinformation can be profile information associated with various users ofthe mobile device including interests and background. The campaignserver 143 can also monitor the activity of various devices to gatherinformation about the devices. The content servers 119, 121, 123, and125 can obtain information about the various devices from the campaignserver 143. In particular examples, a content server 125 uses thecampaign server 143 to determine the types of media clips a user on amobile device 101 would be interested in viewing.

According to various embodiments, the content servers 119, 121, 123, and125 are receiving media streams from content providers such as satelliteproviders or cable providers, manipulating the streams, and sending thestreams to devices using RTP 131. In particular examples, contentservers 119, 121, 123, and 125 access database 141 to obtain desiredcontent that can be used to supplement streams from satellite and cableproviders. According to various embodiments, the content servers alsoread, write, and analyze track data in real-time or near real-time asmedia content is being streamed. In one example, a mobile device 101requests a particular stream. A controller 107 establishes a sessionwith the mobile device 101 using RTSP 133 and the content server 125begins streaming the content to the mobile device 101 using RTP 131.Another controller 105 connected to a load balancer may also be used. Inparticular examples, the content server 125 obtains profile informationfrom campaign server 143.

In some examples, the content server 125 can also obtain profileinformation from other sources, such as from the mobile device 101itself. Using the profile information, the content server can select aclip from a database 141 to provide to a user. In some instances, theclip is injected into a live stream without affecting mobile deviceapplication performance. In other instances, the live stream itself isreplaced with another live stream. The content server handles processingto make the transition between streams and clips seamless from the pointof view of a mobile device application. In still other examples,advertisements from a database 141 can be intelligently selected fromthe database 141 using profile information from a campaign server 143and used to seamlessly replace default advertisements in a live stream.Content servers 119, 121, 123, and 125 have the capability to manipulateRTP packets to allow introduction and removal of media content.

According to various embodiments, the content server 125 continuallyobtains information from a variety of sources. In particularembodiments, the content server 125 obtains statistical information frommobile device 101 including time duration, channel switching events andfrequency, screen brightness, volume settings, commercial interestlevels, etc. The content server 125 may also obtain network statisticssuch as packet transmission rates, throughput, latency, etc. Accordingto various embodiments, the content server 125 can store thisinformation in a database. However, the techniques of the presentinvention recognize that much of this information is time dependent. Forexample, it may be useful to store information about how many channelchanges occur when programming changes or a particular commercial isshown. The techniques and mechanisms of the present invention allowstorage of this information in an efficient and easily accessiblemanner. In particular embodiments, time dependent information can beembedded in a media stream in an existing track or a new track.According to various embodiments, an RTP stream is modified to includestatistical information aggregated from numerous sources, such as theaverage number of users in a particular market viewing a program or theaverage packet transmission rates for a specific sequence. In particularembodiments, the data is stored in a time-correlated manner. Forexample, the number of channel changes occurring when a commercialbegins can be recorded in the media track at the location when thecommercial begins.

The content server records the information in real time or nearreal-time to allow extraction of the information during analysis orsubsequent playback. In particular embodiments, the content server maydetermine that packet drop rates at a particular point in a stream aretoo high and the content server may switch to a lower transmission ratestream. In another example, the content server may determine that alarge percentage of viewers change channels when a particular commercialis played and may insert an alternative commercial. According to variousembodiments, RTP streams and packets may be manipulated based oninformation embedded in media tracks.

FIG. 2 illustrates one example of an RTP packet. An RTP packet 201includes a header 211. According to various embodiments, the header 211includes information such as the version number, amount of padding,protocol extensions, application level, payload format, etc. The RTPpacket 201 also includes a sequence number 213. Client applicationsreceiving RTP packets expect that the sequence numbers for receivedpackets be unique. If different packets have the same sequence number,erroneous operation can occur. RTP packets also have a timestamp 215that allows jitter and synchronization calculations. Fields 217 and 219identify the synchronization source and the contributing source.Extensions are provided in field 221. Data is provided at 223.

According to various embodiments, data 231 holds actual media data suchas MPEG frames. In some examples, a single RTP packet 201 holds a singleMPEG frame. In many instances, many RTP packets are required to hold asingle MPEG frame. In instances where multiple RTP packets are requiredfor a single MPEG frame, the sequence numbers change across RTP packetswhile the timestamp 215 remains the same across the different RTPpackets. Different MPEG frames include I-frames, P-frames, and B-frames.I-frames are intraframes coded completely by itself. P-frames arepredicted frames which require information from a previous I-frame orP-frame. B-frames are bi-directionally predicted frames that requireinformation from surrounding I-frames and P-frames.

Because different MPEG frames require different numbers of RTP packetsfor transmission, two different streams of the same time duration mayrequire different numbers of RTP packets for transmission. Simplyreplacing a clip with another clip would not work, as the clips may havedifferent numbers of RTP packets and having different impacts on thesequence numbers of subsequent packets.

According to various embodiments, each track of metadata can berepresented in a stream of RTP packets for transport/recording andplayback within a subsequent RTSP session. As background, the clientplayer negotiates which RTP tracks to set up during negotiation of anRTSP session with a RTSP/RTP server. In particular embodiments, theclient player has the ability to synchronize and use tracks it isrequesting. It should be recognized that a variety of mechanisms can beused to packetize media in their native track formats into RTP, and manyways to record new metadata back into a file are contemplated. It shouldbe noted that a new metadata track can be added to the disk content asnew streams of RTP packets are synchronized to the audio and video RTPpacket streams. Recording metadata tracks can occur on a clientrecording during playback or on the server during delivery, or incombination.

FIG. 3 illustrates one example of an RTP packet stream that may be usedwith the techniques of the present invention. An RTP packet stream 301includes individual packets having a variety of fields and payload data.According to various embodiments, the fields include a timestamp 303,sequence 305, marker 307, etc. The packets also include payload data 309holding MPEG frames such as I, P, and B-frames. Timestamps for differentpackets may be the same. In particular examples, several packetscarrying portions of the same I-frame have the same time stamp. However,sequence numbers are different for each packet. Marker bits 307 can beused for different purposes, such as signaling the starting point of anadvertisement.

According to various embodiments, packets with sequence numbers 4303,4304, and 4305 carrying potions of the same I-frame and have the sametimestamp of 6. Packets with sequence numbers 4306, 4307, 4308, and 4309carry P, B, P, and P-frames and have timestamps of 7, 8, 9, and 10respectively. Packets with sequence numbers 4310 and 4311 carrydifferent portions of the same I-frame and both have the same timestampof 11. Packets with sequence numbers 4312, 4313, 4314, 4315, and 4316carry P, P, B, P, and B-frames respectively and have timestamps 12, 13,14, 15, and 16. It should be noted that the timestamps shown in FIG. 3are merely representational. Actual timestamps can be computed using avariety of mechanisms.

For many audio encodings, the timestamp is incremented by thepacketization interval multiplied by the sampling rate. For example, foraudio packets having 20 ms of audio sampled at 8,000 Hz, the timestampfor each block of audio increases by 160. The actual sampling rate mayalso differ slightly from this nominal rate. For many video encodings,the timestamps generated depend on whether the application can determinethe frame number. If the application can determine the frame number, thetimestamp is governed by the nominal frame rate. Thus, for a 30 f/svideo, timestamps would increase by 3,000 for each frame. If a frame istransmitted as several RTP packets, these packets would all bear thesame timestamp. If the frame number cannot be determined or if framesare sampled a periodically, as is typically the case for softwarecodecs, the timestamp may be computed from the system clock

While the timestamp is used by a receiver to place the incoming mediadata in the correct timing order and provide playout delay compensation,the sequence numbers are used to detect loss. Sequence numbers increaseby one for each RTP packet transmitted, timestamps increase by the time“covered” by a packet. For video formats where a video frame is splitacross several RTP packets, several packets may have the same timestamp.For example, packets with sequence numbers 4317 and 4318 have the sametimestamp 17 and carry portions of the same I-frame.

FIG. 4 illustrates one example of RTP packet stream modification. An RTPpacket stream 401 includes individual packets having a variety of fieldsand payload data. According to various embodiments, the fields include atimestamp 403, sequence 405, marker 407, etc. The packets also includepayload data 409 holding MPEG frames such as I, P, and B-frames.Timestamps for different packets may be the same. In particularexamples, several packets carrying portions of the same I-frame have thesame time stamp. However, sequence numbers are different for eachpacket. Marker bits 407 can be used for different purposes, such assignaling the starting point of an advertisement. According to variousembodiments, metadata searches allow the introduction of targetedadvertising that can be inserted seamlessly into an RTP stream.

According to various embodiments, packets with sequence numbers 4303,4304, and 4305 carrying potions of the same I-frame and have the sametimestamp of 6. Packets with sequence numbers 4306, 4307, 4308, and 4309carry P, B, P, and P-frames and have timestamps of 7, 8, 9, and 10respectively. According to various embodiments, a content server removesmultiple packets from an RTP packet stream 401, including packets withsequence numbers 4310 through 4316. The packets with sequence numbers4310 and 4311 carry different portions of the same I-frame and both havethe same timestamp of 11.

Packets with sequence numbers 4312, 4313, 4314, 4315, 4316 carry P, P,B, P, and B-frames respectively and have timestamps 12, 13, 14, 15, and16. The spliced stream now ends at packet with sequence number 4309carrying a P-frame. A B-frame is included in packet having sequencenumber 4307. It should be noted that B-frames sometimes may depend oninformation included in a subsequent I-frame which has been removed.Although having a few B-frames lacking reference frames is not extremelydisruptive, it can sometimes be noticed. Therefore, the techniques ofthe present invention recognize that in some embodiments, the lastpackets left in a stream prior to splicing should be an I-frame or aP-frame.

According to various embodiments, now that a portion of the RTP streamhas been removed, an RTP sequence 411 can be inserted. In particularexamples, the RTP sequence inserted 411 begins with an I-frame forsubsequent P and B-frames to reference. Without an I-frame forreference, an RTP sequence inserted may begin with a partial orincomplete picture. The packets for insertion are modified to havesequence numbers following the last sequence number of spliced packetstream 401. RTP insertion sequence 411 has sequence numbers 4310 -4317corresponding to packets carrying I, I, I, B, P, P, B, B, framesrespectively, with the I-frame carried in three packets with the sametime stamp of 11 and the B, P, P, B, an B-frames having timestamps of12-16 respectively.

For example, packets with sequence numbers 4317 and 4318 have the sametimestamp 17 and carry portions of the same I-frame. In some instances,the number of packets in the RTP sequence removed 421 will be exactlythe same as the number of packets in the RTP sequence for insertion 411.However, in many instances, the number of packets removed and insertedwill differ. For example, some frames may require more than one packetfor transmission. Although timestamps can be configured to be the same,so that a 5 second clip can be replaced with another 5 second clip, thenumber of packets and consequently the sequence numbers can be thrownaskew. According to various embodiments, packet with sequence number4309 is referred to herein as a data stream end point packet. Packetwith sequence number 4318 is referred to herein as a data stream restartpoint packet. Packets with sequence numbers 4310 and 4316 in removedsequence are referred to herein as the removed sequence start packet andthe removed sequence end packet respectively. Packets with sequencenumbers 4310 and 4316 in the insertion sequence are referred to hereinas the insertion sequence start packet and the insertion sequence endpacket respectively.

Consequently, the content server maintains a current sequence number perRTP data stream and modified subsequent packets after removing andinserting streams. For example, packets having timestamp 17 are modifiedto have sequence numbers 4318 and 4319 instead of 4317 and 4318. Thecontent server then proceeds to update subsequent timestamps in the RTPdata stream. According to various embodiments, this operation isuniquely performed at a content server because the content server hasinformation about individual mobile devices and also is able to knowinformation about the sequence numbers of an entire content stream. Acontent provider may not know information about individual mobiledevices, whereas a network device or network switch may not receive alldata packets in a sequence. Some packets may have been dropped whileothers may have been transmitted on different paths.

FIG. 5 is a process flow diagram showing one technique for embeddingdata in media tracks. At 501, metadata content for a media stream isextracted and analyzed. At 503, the data is obtained from clientdevices. The data may include user device configurations, user events,channel changes, notes, volume and brightness settings, client playerinformation, client feedback, etc. At 505, network data is obtained fromnetwork devices. Network data may also be obtained from client devicesas well. Network data my include transmission rates, packet drop rates,throughput, etc. At 509, data is aggregated from client and networkdevices. In particular embodiments, data may also be received from othersources, such as chat servers with information corresponding toparticular programming. Data is aggregated and written in atime-correlated manner to a new or existing track in the media stream at511. The data may be written in real-time or near real-time. At 513, themedia stream is stored. In some examples, media stream may continuallyhave new data written as track information. In particular instances, itmay be useful to prune some of this data to allow efficient retrievaland access during subsequent playback and analysis.

FIG. 6 is a process flow diagram showing a technique for modifying amedia stream based on information embedded in a track. At 601, metadatacontent for a particular media stream is analyzed. According to variousembodiments, analysis is done for only metadata content for an immediatetime period such as 10 minutes of a most recently presented stream. At603, a media stream is modified based on metadata content. In particularembodiments, advertisements corresponding to search patterns, tags,strings, and sequences may be selected and inserted into the mediastream based on user data and network data included in the media stream.For example, if user data indicates that a large percentage of userschanged channels when a particular advertisement was shown, analternative advertisement may be selected. In particular embodiments,user data for a particular demographic or geographic group may indicatethat an alternative advertisement should be selected. At 605,alternative advertising is selected. At 607, media stream with differenttransmission rates may be selected. According to various embodiments,network data may indicate that a particular sequence in a media streamcauses a large number of packet drops. A lower bit rate stream may beselected for transmission to user devices in a seamless and efficientmanner. At 609, the media stream is provided for subsequent playback.

FIG. 7 illustrates one example of a content server that can perform livestream modification. According to particular embodiments, a system 700suitable for implementing particular embodiments of the presentinvention includes a processor 701, a memory 703, an interface 711, anda bus 715 (e.g., a PCI bus or other interconnection fabric) and operatesas a streaming server. When acting under the control of appropriatesoftware or firmware, the processor 701 is responsible for modifying andtransmitting live media data to a client. Various specially configureddevices can also be used in place of a processor 701 or in addition toprocessor 701. The interface 711 is typically configured to end andreceive data packets or data segments over a network.

Particular examples of interfaces supports include Ethernet interfaces,frame relay interfaces, cable interfaces, DSL interfaces, token ringinterfaces, and the like. In addition, various very high-speedinterfaces may be provided such as fast Ethernet interfaces, GigabitEthernet interfaces, ATM interfaces, HSSI interfaces, POS interfaces,FDDI interfaces and the like. Generally, these interfaces may includeports appropriate for communication with the appropriate media. In somecases, they may also include an independent processor and, in someinstances, volatile RAM. The independent processors may control suchcommunications intensive tasks as packet switching, media control andmanagement.

According to various embodiments, the system 700 is a content serverthat also includes a transceiver, streaming buffers, an program guideinformation. The content server may also be associated with subscriptionmanagement, logging and report generation, and monitoring capabilities.In particular embodiments, functionality for allowing operation withmobile devices such as cellular phones operating in a particularcellular network and providing subscription management. According tovarious embodiments, an authentication module verifies the identity ofdevices including mobile devices. A logging and report generation moduletracks mobile device requests and associated responses. A monitor systemallows an administrator to view usage patterns and system availability.According to various embodiments, the content server 791 handlesrequests and responses for media content related transactions while aseparate streaming server provides the actual media streams.

Although a particular content server 791 is described, it should berecognized that a variety of alternative configurations are possible.For example, some modules such as a report and logging module 753 and amonitor 751 may not be needed on every server. Alternatively, themodules may be implemented on another device connected to the server. Inanother example, the server 791 may not include an interface to anabstract buy engine and may in fact include the abstract buy engineitself. A variety of configurations are possible.

In the foregoing specification, the invention has been described withreference to specific embodiments. However, one of ordinary skill in theart appreciates that various modifications and changes can be madewithout departing from the scope of the invention as set forth in theclaims below. Accordingly, the specification and figures are to beregarded in an illustrative rather than a restrictive sense, and allsuch modifications are intended to be included within the scope ofinvention.

1. A method, comprising: receiving a media stream, the media streamincluding a video track and an audio track; transmitting the mediastream to a plurality of user devices over a network including aplurality of network devices; receiving user data from the plurality ofuser devices; embedding the user data in a time-correlated manner in atrack associated with the media stream; storing the media stream forsubsequent playback.
 2. The method of claim 1, wherein user datacomprises channel changes and device settings.
 3. The method of claim 2,wherein the user data is embedded in a new track in the media stream. 4.The method of claim 1, further comprising receiving network data fromthe plurality of network devices.
 5. The method of claim 4, whereinnetwork data comprises transmissions rates.
 6. The method of claim 5,wherein the network data is embedded in a new track in the media stream.7. The method of claim 1, further comprising receiving network data fromthe plurality of network devices.
 8. The method of claim 1, wherein theuser data indicates the percentages of user devices switching channelswhen a particular portion of the media stream is played.
 9. The methodof claim 1, wherein user data comprises commercial feedback and userratings.
 10. A system, comprising: means for receiving a media stream,the media stream including a video track and an audio track; means fortransmitting the media stream to a plurality of user devices over anetwork including a plurality of network devices; means for receivinguser data from the plurality of user devices; means for embedding theuser data in a time-correlated manner in a track associated with themedia stream; means for storing the media stream for subsequentplayback.
 11. The system of claim 10, wherein user data compriseschannel changes and device settings.
 12. The system of claim 11, whereinthe user data is embedded in a new track in the media stream.
 13. Thesystem of claim 10, further comprising means for receiving network datafrom the plurality of network devices.
 14. The system of claim 13,wherein network data comprises transmissions rates.
 15. The system ofclaim 14, wherein the network data is embedded in a new track in themedia stream.
 16. The system of claim 10, further comprising means forreceiving network data from the plurality of network devices.
 17. Thesystem of claim 10, wherein the user data indicates the percentages ofuser devices switching channels when a particular portion of the mediastream is played.
 18. The system of claim 10, wherein user datacomprises commercial feedback and user ratings.
 19. A computer readablemedium having computer code embodied therein, the computer readablemedium comprising: computer code for receiving a media stream, the mediastream including a video track and an audio track; computer code fortransmitting the media stream to a plurality of user devices over anetwork including a plurality of network devices; computer code forreceiving user data from the plurality of user devices; computer codefor embedding the user data in a time-correlated manner in a trackassociated with the media stream; computer code for storing the mediastream for subsequent playback.
 20. The computer readable medium ofclaim 19, wherein user data comprises channel changes and devicesettings.